feat(functions): add unicodeRegExp option to schema core function#2809
Open
mtso wants to merge 5 commits into
Open
feat(functions): add unicodeRegExp option to schema core function#2809mtso wants to merge 5 commits into
mtso wants to merge 5 commits into
Conversation
Author
|
@mnaumanali94 / @frankkilcommins , when you get the chance, could you please take a look? |
d02c697 to
a66cd15
Compare
|
@mnaumanali94 @frankkilcommins @mtso — any chance we can get this merged? |
slegarraga
approved these changes
May 24, 2026
Contributor
slegarraga
left a comment
There was a problem hiding this comment.
Useful addition for schemas with Unicode property names — unicodeRegExp opt-in on the schema function keeps default behavior unchanged (#2419).
Ajv instance caching keyed by options is a nice touch; tests + docs updated. LGTM.
This was referenced May 27, 2026
Closed
pull Bot
pushed a commit
to nagyist/camunda-zeebe
that referenced
this pull request
Jun 3, 2026
## Description Switch the `openapi-lint` CI job from upstream `@stoplight/spectral-cli` + pinned `@stoplight/spectral-rulesets` to the Camunda fork [`@camunda8/spectral-cli`](https://www.npmjs.com/package/@camunda8/spectral-cli). The fork is a single pre-bundled package (no transitive dependency on `@stoplight/spectral-rulesets`) that fixes three upstream issues: 1. **nimma null-deref** — the `duplicated-entry-in-enum` rule crashes on `null` example values. The fork adds null guards to the JSONPath filter. 2. **Unicode regex false positives** — Ajv rejects valid Unicode patterns (e.g. `\p{L}`) because `unicodeRegExp` defaults to `false`. The fork integrates [PR camunda#2809](stoplightio/spectral#2809) and defaults `unicodeRegExp` to `true`. 3. **`ignoreUnknownFormat` at ruleset level** — allows rulesets to suppress `unrecognized-format` warnings without requiring CLI flags. Fork repo: https://github.com/camunda/camunda-spectral ## Changes ### CI workflow (`.github/workflows/ci.yml`) - Replace `@stoplight/spectral-cli@6.16.0` + `@stoplight/spectral-rulesets@1.22.2` with `@camunda8/spectral-cli@6.16.1` - Simplify install step to a single `npm install -g` call - Remove the `spectral-rulesets` pinning workaround comment ### Spectral ruleset (`.spectral.yaml`) - Add `ignoreUnknownFormat: true` to suppress `unrecognized-format` warnings on YAML partials (eliminates 43 warnings on the file-level pass) - Promote `oas3-valid-media-example` from `warn` to `error` (all media example issues are now fixed) - Keep `oas3-valid-schema-example` at `warn` — ScopeKey uses `oneOf` with structurally identical branches (`ProcessInstanceKey`, `ElementInstanceKey`), causing "must match exactly one schema in oneOf" on any ScopeKey example. Changing `oneOf` to `anyOf` would fix the warning but breaks Java code generation. 4 warnings remain from this. - Remove the `TODO` comment about restoring severity (no longer needed for media examples) ### OpenAPI spec fixes - `decision-definitions.yaml`: Fix example `decisionDefinitionId` from `1234-5678` (starts with digit, violates `^[\p{L}_]...` pattern) to `my-decision` - `system.yaml`: Add `type: string` to nullable `stage` property (Spectral requires `type` alongside `nullable`), change example from `null` to `"prod"` ### What was NOT changed (and why) - `keys.yaml` ScopeKey `oneOf` — left as-is because changing to `anyOf` alters the generated Java classes and breaks the build (confirmed by CI failure on earlier push) - `process-instances.yaml` `ancestorElementInstanceKey` `oneOf` — same reason; changing to `allOf` breaks codegen Closes camunda#54071
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2419.
Checklist
Does this PR introduce a breaking change?
Screenshots
Before:
After:
Added unicodeRegExp to core function docs

Additional context
Adds an option
unicodeRegExpto theschemacore function. Defaults to "false". When "true", uses the unicode flag "u" with "pattern" and "patternProperties" fields during schema validation; otherwise does not use the "u" flag when "false" or omitted.The
unicodeRegExpoption is optional, and thus backwards compatible with the existing behavior of spectral'sschemacore function. When the option is omitted, the behavior is defaulted to "false".The
unicodeRegExpoption is also added as an optional flag tooasSchemaandoasExampleoas functions. To preserve the existing behavior of the standard oas ruleset,unicodeRegExp: falsehas been explicitly added to the standardoasruleset'sduplicated-entry-in-enum,oas2-valid-schema-example,oas2-valid-media-example,oas3-valid-media-exampleandoas3-valid-schema-examplerules.Adding this option allows rulesets that use the
schemacore function to opt into using the unicode "u" flag when validating the "pattern" and "patternProperty" fields.Adding this option to
oasExampleandoasSchemaalso allows rulesets that extend fromspectral:oasto replace theoas3-valid-media-exampleandoas3-valid-schema-examplerules with a version that opts into using unicode regular expressions. Doing so is currently a little involved, though, requiring re-specifying thegivenblock of the rules as shown below. But it at least makes the option available to extending rulesets.